home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 438 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.2 KB
  1. Path: tbj.dec.com!diamond
  2. From: diamond@tbj.dec.com (Norman Diamond)
  3. Newsgroups: comp.std.c
  4. Subject: Re: sizeof(char) ~= sizeof(float)
  5. Date: 26 Feb 1996 01:46:09 GMT
  6. Organization: Digital Equipment Corporation Japan , Tokyo
  7. Message-ID: <4gr3d1$dca@usenet.pa.dec.com>
  8. References: <WALD.96Feb24131532@woodpecker.lcs.mit.edu>
  9. Reply-To: diamond@jrdv04.enet.dec-j.co.jp (Norman Diamond)
  10. NNTP-Posting-Host: jit533.tbj.dec.com
  11.  
  12. In article <WALD.96Feb24131532@woodpecker.lcs.mit.edu>, wald@theory.lcs.mit.edu (David Wald) writes:
  13. >During a recent recurrence of the perennial "how big is an int"
  14. >discussion on comp.lang.c.moderated, I described a freestanding C
  15. >implementation I'd dealt with in which, as in some other word-based
  16. >implementations, sizeof(char) == sizeof(long) == sizeof(float).
  17. >However, one quirk of this architecture was that not all
  18. >interpretations of a memory word could see all bits.  In particular,
  19. >though integral types and floats each took one word, a float used 8
  20. >more bits than the integral types.  When a word was used in integral
  21. >operations, the lower 8 bits were invisible and harmless.  Thus you
  22. >could have two sections of memory which could be distinguished when
  23. >viewed through float*'s but not when viewed through char*'s.
  24. >Can such an implementation be ANSI-conformant?
  25.  
  26. At present, I think it can.  As written, the standard does not say whether
  27. types char, signed char, and unsigned char are required to use all bits of
  28. the storage they occupy in determining the values they represent.  Bits
  29. not used are now called "holes" (which is not what they were called by
  30. the base document K&R-I).
  31.  
  32. Rumor has it that Technical Corrigendum 2 will change the standard so that
  33. unsigned char cannot have any holes.  Signed char will still be allowed to
  34. have holes, and char will still have to behave either as unsigned char (no
  35. holes) or as signed char (identical holes).
  36.  
  37. >The basic argument against, presented by Tanmoy Bhattacharya, is that
  38. >memory compare, and possibly memory copy functions, can't be implemented
  39. >in a portable fashion if two dissimilar regions of memory can't be
  40. >distinguished by comparing them char-wise.
  41.  
  42. Is that really what he said?  I'm sure Mr. Bhattacharya knows many parts
  43. of the standard which cannot be implemented in a portable fashion.  Every
  44. implementation has to provide some degree of portability to some kinds of
  45. programs -- that is what the standard requires -- but an implementation
  46. itself does not port so easily.  So, what is one more minor grunge?
  47.  
  48. >(I'm unsure about the memory copy, since I've forgotten whether the
  49. >implementation actually preserved the hidden 8 bits when you copied a char.)
  50.  
  51. If you assign one char to another using an assignment operator, it doesn't
  52. have to do so.  (Except of course that after TC2, if you use unsigned chars,
  53. then there can't be hidden bits any more.)
  54.  
  55. If you use memcpy or possibly if you play tricks with union types, you can
  56. force it to copy all the bits.
  57. --
  58.  <<  If this were the company's opinion, I would not be allowed to post it.  >>
  59. "I paid money for this car, I pay taxes for vehicle registration and a driver's
  60. license, so I can drive in any lane I want, and no innocent victim gets to call
  61. the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
  62.